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CAPACITY ALLOCATION SYSTEM USING 
SEMI-AUTONOMOUS NETWORK 
ELEMENTS TO IMPLEMENT AND 

CONTROL A TRANSMISSION SCHEDULE 

This application is a continuation of provisional appli- 
cation No. 60/072,339, filed Jan. 23, 1998 and provisional 
application No. 60/075,101, filed Feb. 18, 1998. 

FIELD OF THE INVENTION 

This invention relates to communication methods and 
apparatus for providing network management, bandwidth 
and path control in a heterogeneous network that may be 
composed of multiple vendor equipment and transmission 
paths. More specifically, the communication system con- 
cerns semi- autonomous implementation components within 
a management hierarchy to globally manage multiple vendor 
elements while satisfying local network demands. 

BACKGROUND OF THE INVENTION 

Telecommunications services have, for many years, 
attempted to optimize or minimize bandwidth usage 
between network elements. Since the modem communica- 
tions era, brought about by the theories of Shannon, tele- 
communications engineers have been keenly aware of the 
need to provide optimal, or at least good solutions, to 
bandwidth allocation problems in point-to-point and point- 
to-multipoint networks. 

In wireless communication systems, solutions to band- 
width allocation problems can be seen in the way data is 
modulated to "share" finite resources. For example, time 
division multiple access ("TDMA") provides a means for 
multiple stations to access time slots on satellite carriers and 
thereby "share" bandwidth resources. Code Division Mul- 
tiple Access ("CDMA") provides a means to use code 
division modulation techniques (time and frequency 
modulation) for multiple point access to a predetermined 
range of bandwidth and thereby "share" bandwidth space. 
Likewise, frequency division multi-access ("FDMA") pro- 
vides a means to divide up and share a finite bandwidth 
resource. 

More elaborate schemes to dedicate bandwidth in accor- 
dance with a predetermined transmission schedule and 
modulation plan can be seen in U.S. Pat. No. 5,592,470 to 
Rudrapatna et al,, ("Rudrapatna") issued Jan. 7, 1997, (the 
"Rudrapatna patent"). The Rudrapatna patent concerns a 
terrestrial micro-port network that allocates bandwidth to 
terrestrial micro -port receivers based on a pre -determined 
schedule and modulation plan. The p re-determined schedule 
and plan may be subsequently modified by dynamic 
demands on the micro-ports. The network can then satisfy 
the dynamic demands by moving channels between modu- 
lation and polarity schemes in pre -determined amounts. 

In wireless networks, certain communications links 
require more bandwidth and power resources than others. 
This is necessary to maintain specified information 
throughput, to provide appropriate grades of service or due 
to varying site configurations (e.g., different antenna sizes). 
Whenever a change in network resource allocations is 
required to match varying traffic requirements, a new trans- 
mission plan may or may not be implemented. This may 
necessitate programming, transmitting and receiving com- 
munications equipment, e.g., amplifiers, modulators and 
demodulators, to support the new resource assignments. 
These and other problems in bandwidth allocation in a 
multi-vendor network are addressed by the present inven- 
tion. 



51,250 Bl 

2 

SUMMARY OF THE INVENTION 

The methods and apparatus disclosed herein may assign 
and re -assign available transmission resources in point-to- 
point, multipoint and broadcast wireless networks. This may 
be accomplished on the basis of information capacity and 
connectivity requirements between transmitters and receiv- 
ers of communications links at the time of assignment or 
reassignment. The system may also provide a network 
administrator with novel tools and automated methods to 
define and implement network transmission plans and to 
modify allocation decisions as traffic requirements change. 

The system may provide the tools to efficiently allocate 
transmission resources. These tools help implement the 

15 communications links that form wireless networks. An opti- 
mum resource or a "good fit" allocation is achieved when 
network users have just enough information transmission 
capacity to perform their tasks. One way to accomplish 
optimal or good transmission resource allocations in a 

20 wireless network is to analyze network users' usage patterns 
and allocate capacity according to a time-varying schedule. 

By analyzing network usage patterns, a management 
component can determine a transmission plan schedule that 
efficiently allocates the satellite bandwidth available to the 

25 network based on historical usage patterns. The manage- 
ment component may automatically schedule and imple- 
ment a transmission plan. As the network users' require- 
ments change, the management component may update or 
modify the scheduled transmission plans to satisfy the new 

3 Q requirements. 

The system may automate implementation of transmis- 
sion plans by reprogramming the system when predeter- 
mined parameters are reached. For example, the manage- 
ment component may determine a transmission plan from a 

35 historical analysis of bandwidth requirements between sta- 
tions. This transmission plan may be automatically deployed 
to the network. The management component can then moni- 
tor and analyze network allocation demands to determine a 
new transmission plan. The new transmission plan can then 

40 be automatically deployed in the network when predeter- 
mined parameters are reached, such as, average change in 
bandwidth, e.g., bandwidth in use/bandwidth in the trans- 
mission plan, exceeds a predetermined amount or if a 
predetermined amount of time has transpired. The transmis- 

45 sion plans may be propagated as generic network commands 
and translated into corresponding equipment parameters and 
associated control commands as required for reconfiguring 
network equipment elements. Thus, the system may gener- 
ate and distribute equipment configurations to network ele- 

50 ments to reprogram for synchronized execution at predeter- 
mined times. 

The system further controls and schedules bandwidth 
between network elements to consider other network factors 
such as economic constraints. In a wireless communications 

55 network, each communications carrier should have just 
enough bandwidth and power necessary to meet the needs of 
its corresponding users. Although optimum resource alloca- 
tion is the primary goal, sub-optimum allocation may be 
tolerated when economic constraints may limit transmission 

60 resources to finite amounts. Thus, for example, a dynamic 
bandwidth requirement at a network station may require an 
increase in bandwidth allocation from the station, such as 
when the queuing depth reaches a predetermined amount at 
the station switch. The station may have additional capacity 

65 available on an available communication link, however, the 
incremental capacity of the link may far exceed the band- 
width required to reduce the depth of the communication 
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queue. Furthermore, the financial cost of the incremental The IC is semi-autonomous, e.g., it can translate alloca- 

capacity may exceed the cost of waiting for network usage tion commands from a management component into execut- 

to decrease to reduce the depth of the queue. The system, in able commands for its associated network elements without 

this case, would allow the network to back up and flow having direct, full-time contact with the network manage- 

control the user data __before the system_wo uld allocate s ment component. The IC may store pre-programmed 

jo^itiond_cjpacity. The- sy^m provides methods to use ] parameters, transmission plans, or collection commands for 

finU| transmission resources b^eiiabling power and band- ? automatic execution. The IC may map a network program- 
, .width, ^ changmg-comJ. min language command set or generic allocation command 

^municajignsaequirements ^-m-satelhte ne^ks. However, tQ a vendor ific command ^ JC 

the capabilities of the system are applicable to all wireless ^ tU * 4 . t M . . . ; 

networks .ha. can be modeled as a collection of transmitters, 10 th ' managemeDt component to receive permission to access 

transmission resources, and receivers. n f twork baDdwidth > t0 report the unavailability of network 

rj, . . . u . - elements, or to request different allocation parameters if or 

- lite system provides a means to manage be erogeneous or when , oca , demands excee(J ^ , c . £ ed allo . 

muUipte vendor network equipment over heterogeneous or calk)ns ^ , he |c ma ^ ^ ' ^ conlro , oyer 

multiple vendor transmission resources with multiple trans-' 1C „ ot „,„u fll/lman)r „,-i; '' ■ , • . r 

. . rt u iL i_ L , ^ 15 network elements while maintaining or executing a man- 
mission paths. One such path may be via programmable C-,' aeement olan 
Ku-, or Ka- band satellite networks. Other paths may be via ^ 
S discrete carriers available on a preprogrammed networks . In the semi -autonomous network management scheme 
V such as the Inmarsat, Globalstar or Iridium satellite systems. : *f*™?*> transmission schedules may be loaded in advance 
Yet other paths may bevia third party medium or broadband' , n of the im plementation of the scheduled transmission plans, 
networks such as the envisioned Teledesic satellite network, Then ' at a predetermined time, the network can switch over 
Yet another path may be over a programmable or managed 10 the new transmission plan to implement the optimal, or at 
network such as the Intelsat global satellite system. Thus, the least S ood solution, beforc more complicated dynamic band- 
system provides a means to define and manage capacity Wldth Nation algorithms would need to be employed, 
between network elements where the network may be a 2$ In addition to automatically implementing scheduled 
combination of a discrete bandwidth allocation network transmission plans generated by the management 
managed by an external system, a semi -programmable component, the system may also perform network usage 
medium or broadband network wherein a varying a mount of analysis. Automated network usage analysis may require 
bandwidth may be allocated from an externally managed that the management component have access to traffic data 
resource and a fully-programmable network where the 3Q collected for the network. The data may be collected auto- 
resource is managed by a network management component, matically or manually by the management component or the 
Thus, the management system provides a nearly transparent implementation component may interact with the elements 
means by which an operator, user or network element may m the network to collect the usage data. The management 
place demands on the network and the management system component may use statistical methods to analyze the gath- 
may satisfy those demands based on a least cost algorithm, 35 erecJ network usage data to suggest or implement optimize 
quality of service parameters and pre-defined or time- transmission plans for efficient use of the available resources 
^ ^varying transmission plans. according to a schedule. 

1 The management system described may configure the: Efficient use of bandwidth spectrum may be achieved on 

f ■ transmission elements. (transmitters and receivers) in a wirer various levels in the system. On a first level, bandwidth may 
{■ less network to implement a specified allocation of trans'- 40 be scheduled in accordance with a historical analysis of 

yi\ mission resources according to varying, scheduled or ad-hoc . demands on the network. For example, it may be determined 
; capacity requirements. The system maintains a schedule of that Monday morning traffic is mostly outbound (i.e., from 
^ | * transmission plan implementations and may automatically^ a central earth station to a mobile station). On Fridays, 

\ perform each implementation at a scheduled time. / J however, most of the traffic is in the opposite direction (i.e., 

The semi-autonomous network management system 4S from mobile stations back to the central earth station). In this 

essentially consists of two semi-autonomous components. instance, an assymetric channel may be opened for Monday 

The first component is the Implementation Component (IC) traffic to provide higher outbound data and a slower speed 

which executes at a site containing network transmission return path. Then the opposite allocation may be established 

elements and the second is a Management Component (MC) f° r Friday's traffic (e.g., a high speed channel from a mobile 

which executes at a network management site. These com- 50 station to the central station and a low speed acknowledg- 

ponents may be connected via a user datagram Internet m ent channel from the central station back to the mobile 

protocol messaging format. station). This may provide an optimal, or at least a cost- 

At the heart of the system is the IC. The IC may be a effective solution for the capacity requirements at a particu- 

stand-alone application program that controls one or more * ar ^ me - 

network elements. A network element may be the station or 55 On a second level, the system may allocate capacity based 
communication equipment physically controlled by an IC. on class of service parameters available, for example, 
Thus, it is usually the case that the network element is a through an Asynchronous Transfer Mode ("ATM") type 
stationary or mobile communications node at a single physi- packet format. For example, a class of service may identify 
cal location. The IC may, however, remotely control a data packets with low priority for a particular application. In 
network element. 60 sucn a case, an expensive satellite carrier may not be 
In one embodiment of the present invention, the IC necessary and a lower-cost transmission resource may be put 
application may execute in a dedicated processing environ- online by the network to pass the required data packets, 
ment such as a PC executing UNIX or other suitable Thus, the present network can mix class of service band- 
operating system such as Windows or DOS. The IC may also width allocation methods with least cost routing decisions 
execute on an integrated or embedded processor such as a 65 based on predetermined parameters programmed in the IC. 
PC on a card environment with an application specific or real The semi-autonomous nature of the network management 
time operating system executing thereon. components may use a datagram protocol for interprocess 
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communication. More specifically, the network components 
may communicate through the use of the User Datagram 
Protocol ("UDP") over an internet protocol ("IP"). Commu- 
nication between the management component and the IC 
may use a polled or interrupt methodology. 

In a polled mode, the management component contacts 
each of the ICs to pass UDP/IP messages or to receive 
Transmission Control Protocol/Internet Protocol ("TCP/IP') 
information from the particular IC, In an interrupt driven 
mode, the IC may attempt to communicate with the man- 
agement component. The interrupt mode may be used to 
reestablish contact with the MC if the IC loses synchroni- 
zation with the network or to pass alarm or other local 
conditions happening at the IC that may not be detected by 
the management component. In the interrupt driven mode, 
the IC may have a preassigned back-up channel or prede- 
termined bandwidth allocation to communicate with the 
management component. The management component may 
be programmed to look for alarm conditions or communi- 
cation attempts from the ICs when predetermined parameter 
thresholds arc reached. 

Additionally, a signaling control mechanism between the 
management component and the ICs is disclosed. The sig- 
naling control mechanize operates to ensure that each of the 
ICs receives the appropriate mcssage(s) and that the trans- 
mission plan may be implemented according to the prede- 
termined schedule. 

The signaling control mechanism between management 
component and implementation components may commu- 
nicate by exchanging the following UDP/IP messages. 

Transmission Control Order 

Abort Order 

Acknowledgment of a Transmission Control or Abort 

Order 
Audit Request 
Audit Response 

A transmission control order ("TCO") specifies new trans- 
mission parameters for a transmitter or receiver. The TCO 
may also specify the implementation time. The implemen- 
tation time may be the time at which elements should begin 
using the transmission parameters specified in the order. 
TCOs are generated by the system to implement a new 
transmission plan. The system sends TCOs to the ICs of 
transmitters and receivers that must change parameters to 
implement the new transmission plan. TCOs may be stored 
on a hard drive or other non-volatile storage so that they are 
preserved through IC restarts and at I C power failures. 

It is possible that an IC may be down or may not be able 
to communicate with the managed equipment at the execu- 
tion time of a TCO. When this happens, the IC may 
implement the current transmission plan or may implement 
a default state when the IC reestablishes communication 
with the managed equipment. 

The IC may send an acknowledgment of a TCO when a 
TCO is received from the system. If any of the requested 
parameter changes cannot be implemented because the 
managed equipment or the configuration files do not support 
it, the IC notifies the management component of this in the 
acknowledgment. 

The IC may also check that the parameter values are valid 
for the managed network equipment. Parameter ranges are 
specified in the Equipment Controller configuration files in 
the IC, discussed further below. 

A confirmation message may not be necessary for report- 
ing the successful implementation of a transmission control 
order. Because the majority of satellite networks implement 
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single links to each remote site, if an IC is not able to 
implement a TCO, the IP connection to the system may be 
lost. The system management component may detect the 
problem from the lack of audit responses. If the system does 
5 not receive an audit response from an IC, the system may 
update the site status and alerts the management component 
alarm. 

An abort order may instruct the IC to cancel any pending 
TCO for the specified transmitter or receiver. The system 

30 may send abort orders when a pending implementation is 
canceled by the Administrator. The IC may send an 
acknowledgment when it receives an abort order. The IC 
may send an acknowledgment when it receives a TCO or 
abort order from the management component. 

35 An audit request may be periodically sent to an IC by the 
management component. The management component may 
send an audit request to check the status of a transmitter or 
receiver. One audit request may be sent for each transmitter 
and receiver being managed by an IC. 

20 An audit response may be sent by an IC when an audit 
request is received from the management component. The 
audit response may contain the current parameter values for 
the transmitter or receiver specified in the audit request. 
An audit response may be similar in structure to a TCO. 

25 It may include the hardware identification for a transmitter 
or receiver and a list of model parameters and their current 
values as reported by the physical hardware. 

The receive frequency model parameter may be a special 
case: the frequency reported by the demodulator may not 

30 match the commanded receive frequency. Sources of fre- 
quency error throughout a wireless carrier transmission 
process may result in an offset between the expected and 
actual receive frequencies. Many demodulators are designed 
to accommodate this frequency offset by searching for the 

35 transmitted carrier in a neighborhood around the com- 
manded receive frequency. However, the system may also 
account for this receive frequency offset when determining 
whether the physical hardware is using the same parameters 
as in the most recently implemented TCO. 

40 The management component may periodically request the 
current parameters from all transmitters and receivers. This 
network auditing function may perform the following func- 
tions: 

Maintains the status of communications between the 
45 management component and the transmitters and 
receivers in the network. 
Detects parameter changes of the managed equipment. 
When a difference between the specified transmission 
parameters for a transmitter or receiver and the managed 
50 equipment is detected, the management component may 
notify a Bandwidth Administrator. The management com- 
ponent operator interface may use an audible as well as 
visual alert to improve the chance that a Bandwidth Admin- 
istrator will notice the difference and act to resolve it. 
55 FIG. 21 shows equipment controller IC (150). IC (150) 
may have a configuration database (152) which stores a 
configuration mapping for end-user receiver and transmitter 
equipment which is interfaced by, for example, serial 
devices (164, 166, 172, 174) and parallel devices (188, 190), 
60 The receiver/transmitter equipment may be from multiple 
vendors and thus the configuration database (152) maps 
commands from the management component (156) to a 
particular device. This feature of the IC may allow the use 
of a generic network control language in commands sent to 
65 IC (150) (discussed further below). 

The system is designed to manage all transmission 
equipment, regardless of manufacturer. To achieve this, the 
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management component deals with model satellite transmit- FIG. 14 is a flowchart illustrating a method of executing 

ters and receivers as illustrated in FIG. 6. a bandwidth allocation request. 

The transmitter and receiver models have the parameters FIG. 15 is a graphical depiction of a UDP datagram 

necessary to implement a wireless link. Only parameters that format employed in the management components, 

relate to the establishment of a wireless link need be 5 F IG. 16 is a functional schematic of the request/command 

included in the transmitter and receiver models. flow direction of the m 

The management component may not require information ^ T _ --.„,.„ . , , „ 

about the physical equipment elements used to implement ^ 17 15 * fl ™ chart Crating a meth ? d of grading, 

the communications links in the managed network. employing, and implementing transmission plans within the 

Therefore, the MC need not map the model parameters 10 ne wor * 

directly to commands for the physical hardware of the FIG - 18 is a graphical depiction of how the methodology 

transmitters and receivers at a site. The IC may have of tne present invention views transmission media as 

information about the physical hardware at its site and may resources. 

map the model parameters to the appropriate commands and FIG. 19 is a graphical representation of the methodology 

responses. 15 of the present invention allocating transmission media 

The IC may read information about the physical hardware resources, 

from the configuration files. These files may specify the FIG. 20 is a graphical depiction of a timing transmission 

information required by the IC to monitor and control the pi an implementation. 

managed equipment a! a site. The IC configuration files may FIG. 21 is a graphical depiction of the command process- 
contain the uiformat.on necessary to convert parameter 20 ; flow in me ; t comroller . 
changes for the model transmitters and receivers into com- ^ T ^, „ . , . 

mands to the physical hardware. FIG ; 22 » a S ra P h 'cal depiction of the process flow for 

network audit processing. 

BRIEF DESCRIPTION OF THE DRAWINGS FIG. 23 is a graphical depiction of the auto command flow 

FIG. 1 is a pictorial schematic of a star topology satellite " with respect ,0 timin S- 

network showing a shared outbound simplex channel and a DETAILED DESCRIPTION OF PREFERRED 

private mbound simplex channel. EMBODIMENT 

FIG. 2 is a pictorial schematic of a mesh topology for a 

satellite network showing shared outbound simplex chan- The system is composed of two software components, the 

nels. 30 Management Component ("MC") and the Implementation 

FIG. 3 is a functional schematic of a transmission equip- Component ("IC") that work together to monitor and control 

ment model depicting modulators, up converters, and the theJransmissionjiiemen^^^ 



loss and gain elements in the circuit, the site antenna, and the The MC includes an operator -interface for configuring, j 

corresponding receiving circuits showing gain and loss ^ monitoring, and controlling the capacity allocation activity^' 
elements, the down converter, and the demodulator. ^ in a wireless network. It may be a Win32 application thatj 
FIG. 4 depicts software components for the semi runs on a Windows NT w^^^^^|n|hvmay beiocated at; 

autonomous network management system of the present r-i a nempjk^Q^e^a^ Configuration,' 
invention. \ $ '?m^ mav be^ 

FIG. 5 is a functional schematic detailing the software ^.accomplished with thejQa3gement_ J c^p^neritll ; r^ MC 
components. At the control site there is a management communicates-with'the other software component, the IC, 
(control) component, a display controller and an event using the Internet Protocol (IP) family of network protocols 
logger component. At the remote site, there is the IC, the as illustrated in FIGS. 4 and 5. 

equipment controller component and a display controller The IC is the application that may communicate with the 

and event logger component. The management transmission 45 physical hardware elements implementing the communica- 
and receiver equipment is further shown as being controlled tions links in a wireless network. The IC may be a Win32 
from the IC equipment control. application that runs on a computer located at each site in the 

FIG. 6 is a functional schematic showing the elements of network. The IC may read a set of configuration files that 
a transmission model that are controlled by the semi- describe the network equipment to be monitored and con- 
autonomous ICs of the present invention. so tolled. These configuration files may be text files and may 

FIG. 7 shows a further functional schematic of the IC be created and modified with a text editor program. In 
systems general, the configuration files are re-usable, that is the same 

™„ ' . c . , , iL - configuration file may be used at multiple sites if the same 

FIG. 8 is a functional schematic showing the software . ° , t . j * u *u •* 

t - . . & 4 . network equipment is used at both sites, 

process architecture of the semi-autonomous network man- . ^ ,^ 

agcraent component. 55 ^ dlscusscd above, the MCs and ICs communicate by 
™„ ft . . " | i P #u . P a exchanging IP messages. FIG, 5 is a representation of the 

FIG. 9 is a functional schematic of the information flow ? •? u *. *u • 

. t , . c . . connectivity between the management component and the 

in the semi-autonomous components of the present inven- . . , , TD , 

t - on v r IC in a wireless network. The IP connections may be 

' . , j . . r. . implemented on the satellite network, through the Internet, 

FIG. 10 is a graphical depiction of the transmission plan 6Q or through a private netw0 rk. A second physical communi- 
allocation of available spectrum. cation path ^totem the MC and the ICs may be used to 

FIG. 11 is a graphical depiction of the transmission plans establish IP communications. Typically, ICs do not commu- 
of a transmission plan schedule. nicate with other ICs; however, communication links may be 

FIG. 12 is a graphical depiction of a transmission plan established between components to further communication 

schedule implemented throughout a particular day. 65 with the MC. 

FIG. 13 is a flowchart illustrating a method of transmis-' The management system is designed around several ele- > 
sion plan deployment and execution. ments. These are the ^ " " ^ ' *• 
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Transmission resource 
Site 

Transmitter 
Receiver 

Transmission element 
\ .Transmission plan- 

Implementation i 

Schedule 

Execution time 
A transmission resource may be a portion of a wireless 
capacity (power and bandwidth) that may be used by the 
transmitters in a network. A site may be a collection of 
transmitters and receivers controlled by a single IC. Nor- 
mally one IC controls all of the transmitters and receivers at 
a network site. However, the transmitters and receivers at a 
network site may be controlled by more than one IC. For 
example, this may occur at a hub site in a satellite network 
with a star configuration. 

A transmitter is an equipment element that modulates an 
information signal so that it may access a wireless media. A 
receiver is an equipment element that demodulates a signal 
received from a wireless media to recover the information 
from the broadcast signal. A transmission element may be a 
transmitter or receiver in the network configuration. 
Although transmitters and receivers may be different and 
perform different functions, the management component 
may perform some operations in which transmitters and 
receivers are both treated the same way. For example, the 
MC may audit the status of all transmitters and receivers in 
the network. The management component may not distin- 
guish between transmitters and receivers when performing 
this auditing operation. 

A wireless link may be created when an information 
signal is modulated by a transmitter and then demodulated 
by one or more receivers. A wireless communication net- 
work is a collection of communications links that enable 
information transfer among the sites in the network. Each 
link requires some of the transmission resources available to 
the wireless network. The allocation of the available trans- 
mission resources among the transmitters in a network is a 
transmission plan. These transmission plans may define the 
information capacity and connectivity requirements between 
the transmitters and receivers in the network. 

Only transmitters may need to be specified in a transmis- 
sion plan. Transmitters generate the signals that use trans- 
mission resources. The number of receivers demodulating a 
wireless signal does not affect the amount of transmission 
resources (bandwidth and power) used to implement the 
link. 

Implementation may be the process of configuring the 
transmitters and receivers in a wireless network to allocate 
the transmission resources as specified in a transmission 
plan. The management component may implement a trans- 
mission plan by sending orders to the ICs controlling the 
transmitters in the transmission plan and the receivers lis- 
tening to those transmitters. These orders may specify the 
transmission parameters for the transmitters and receivers 
and when they should be implemented. The IC may send the 
equipment-specific commands that implement the transmis- 
sion parameters at the specified time. The implementation 
schedule may be a list of all transmission plan implemen- 
tations that may automatically be executed in the future. The 
schedule may be maintained by the MC application. An 
operator may add implementations to the schedule, remove 
implementations from the schedule, and move existing 
implementations to different times. An execution time con- 
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sists of a transmission plan and the time at which the 
transmission will be implemented. The time may be a 
recurring time, for example 1200 UTC every day or 0600 
UTC every Monday. The implementation schedule may be 

5 built from execution times. 

The information architecture of the system applies pri- 
marily to the structure of the database maintained by the 
Management Component and may define the structure of the 
messages exchanged between the management component 

10 and ICs. 

The information maintained by the management compo- 
nent (network configurations, transmission resource 
configurations, transmission plans, etc.) may be stored in a 
relational database. 

15 The management component may require information 
about the wireless networks that it manages. A network may 
be viewed as being composed of sites, transmitters, and 
receivers. Information about these objects, e.g., sites, trans- 
mitters and receivers, and the relationships among them may 

20 constitute a network configuration. A network may be a 
collection of sites that are linked by transmission resources. 
The following information may be specified for each net- 
work managed by the system: 
Name 

25 

Transmission resources available for use by the network 
The system may maintain the following information for each 
network: 

Network ID 
30 Status 

Sites in the network 

A site may be the physical location of an antenna in a 
wireless network. In addition to an antenna, a site may have 
at least one transmitter or receiver. The system may require 
35 that the following information be provided for each site: 

Name 

NMS IP address 

Location (street address, geographic coordinates, etc.) 
40 Contact information (telephone numbers, operators* 
names, radio frequencies, etc.) 
Antenna parameters (size, gain, etc.) 
The system may maintain the following information for each 
site: 
45 Site ID 
Status 

Network to which the site belongs 
Transmitters at the site 
50 Receivers at the site 

Time of last management component transmission to site 
Time of last IC response from site 
In the system, a transmitter may comprise the equipment 
necessary to convert a digital data stream into a carrier for 
55 transmission over a wireless resource. The system may 
require that each transmitter be uniquely named. The system 
may maintain the following information for each transmit- 
ter: 

Transmitter ID 

60 

Status (UP, DOWN, FIXED, UNKNOWN) 
Site where the transmitter is located 
Receivers that should be receiving the transmitter's 
carriers) 

65 The system may track the status of the transmitters in a 
wireless network. Possible status values for the tracked 
components may be: 



01/20/2004, EAST Version: 1.4.1 



US 6,381,250 Bl 



11 



12 



UP the transmitter is currently generating a carrier and is 

under the control of the management component 

DOWN the transmitter is not generating a carrier but is under the 
control of the management component 

FIXED the transmitter is generating a carrier and the management 

component knows the characteristics of the carrier but the 
transmitter is not under management component control 

UNKNOWN the management component does not know if the 
transmitter is generating a carrier 



In Lhe system, a receiver may comprise the equipment 
necessary to receive a carrier transmitted over a wireless 
resource and recover the digital data stream. The following 
information may be specified for each receiver: 

Name 

Transmitter of the carrier the receiver should receive 
The system may maintain the following information for each 
receiver: 

Receiver ID 

Status 

Site where the receiver is located 

A pool may be a collection of transmission resources 
available for use by the managed networks. Each transmis- 
sion resource is a portion of transmission capacity (power 
and bandwidth). The following information may be required 
for each pool: 

Name 

Transmission resources in the pool 
The system may maintain the following information about 
each pool: 

Pool ID 

Networks using the pool 

A transmission resource may be a portion of transmission 
capacity (power and bandwidth). The system may require 
the following information about each transmission resource: 

Description (transponder, provider, etc.) 

Start frequency 

End frequency 

Translation offset 

Power allocation 

Cost metrics 

The system may maintain the following information about 
each transmission resource: 

Transmission resource ID 

Pool to which the Transmission resource belongs 

A transmission plan is an allocation of transmission 
resources to one or more carriers in a wireless network. The 
system may specify the following information about a 
transmission plan: 

Execution time 

Duration 

Comments 

The system may maintain the following information about a 
transmission plan: 
TP ID 

State (UNSCHEDULED, SCHEDULED, PENDING, 
READY, STARTING, ACTIVE, COMPLETED, or 
CANCELLED) 

BARs satisfied by the TP 

The system may manage sites with multiple transmitters 
and receivers. Therefore the system maintains a naming 
scheme for identifying a specific transmitter or receiver at a 
site. 
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FIG. 9 may represents the flow of hardware identification 
information from the IC configuration files to the manage- 
ment component. The identification information may origi- 
nate in the configuration files generated for a site in a 
network. The configuration files for a site may be read by the 
IC. 

FIG. 9 shows the information flow in the system. Each 
transmitter and receiver at a site may be designated by an 
equipment class. Each member of a class is assigned an 
instance number. Together, the equipment class and instance 
identify a unique transmitter or receiver at a site. A Band- 
width Administrator (902) may supply the hardware identi- 
fication when configuring the transmitters and receivers of a 
site for bandwidth management. The flow of information 
shown in FIG. 9 simplifies network configuration mainte- 
nance and reduces the risk of problems due to inconsistent 
configuration information in the network. The circles with a 
slash (914, 916) illustrate that neither the Bandwidth Admin- 
istrator (902) nor the management component (906) require 
access to the configuration files (910). 

The system software components may exchange informa- 
tion by sending and receiving messages using network or 
external connections. The management process may com- 
municate with all of the IC processes. Each IC communi- 
cates only with the management component. 

The User Datagram Protocol (UDP) of the Internet Pro- 
tocol (IP) suite may be used to transport the inter-process 
messages. The system may use the combination of IP 
address and UDP port to identify the ICs in the network. Site 
identification information may not be required in the mes- 
sage if the IP address and port are already available in the IP 
and UDP headers. 

The management and ICs may communicate using several 
types of messages. Although each type of message contains 
different information and fulfills a different purpose, the 
message types share some common characteristics as shown 
in FIG. 15. 

A message is sent as a single UDP datagram 

Only ASCII characters are allowed in a message 

A message is a series of information fields 

Fields are terminated with an ASCII linefeed (LF) 

A message is terminated with an empty field (single LF) 

The first three fields are the same for any message 

(message type, sequence number, and hardware 

identification) 

Although system messages contain only ASCII 
characters, the messages may be compressed before delivery 
via UDP. Messages may then be uncompressed after receipt. 
Fields #4 through #N (1514, 1518) in FIG. 15 are informa- 
tion fields (1524). The fields prior to the information fields 
in a BMF message are header fields (1528), 

Header fields may be present in system messages (1528). 
Typically, the order and format of the header fields are the 
same, regardless of message type. The format of a header 
field is simple: a string terminated by an ASCII linefeed (LF) 
character (1504, 1508 and 1510). The string can contain any 
printable ASCII character except LF. The management and 
ICs may communicate using the following message types: 

Transmission Control Order (TCO) 

Abort Order (ABRT) 

Acknowledgment (ACK) 

Audit Request (AREQ) 

Audit Response (ARSP) 

The mnemonic in parentheses after each message type is 
the identifier used in the first field (1502) of a system 
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message (1526). After the message type field, the next field (46). For example, transmitter (44) has been allocated trans- 

in a system message is a sequence number (1506). The s ^mission media resource (45) for reception by receiver (48) 

management component maintains a sequence number for ^as indicated through up link and down link mappings in 

each piece of managed equipment (e.g. receiver or transmission plan (43). This may represent a combined 

transmitter) in a network. The IC may use the sequence 5 transmission media resource whose overall capacity is the 

number from a request message in the response message. entire discrete amount allocated at transmission media 

Sequence numbers may be used to match responses (ACK resource (45). For example, a dynamic bandwidth require- 

or ARSP) with requests (TCO, ABRT, or AREQ). The use of ment for a connection at a predefined class of service may 

sequence numbers (1506) prevents confusion when multiple be split into two discrete carriers. The discrete carriers may 

responses are received when multiple requests were sent due 10 be represented by the two discrete media resources allocated 

to message delivery delay or temporarily unavailable com- at transmission media resource (45) to provide an overall 

ponents. throughput necessary to accommodate the predetermined 

FIG. 18 illustrates a transmission plan for allocating capacity to support the class of service. The excess capacity 
transmission media resources among transmitters in a net- may be used to provide the time recovered to reassemble the 
work. FIG. 18 shows that a transmission media can be is packets at receiver (48). This methodology is useful in the 
divided up into discrete segments (10). A network manage- instance where, for example, a class of service from a 
ment plan can view discrete segments (10) of bandwidth as particular end-user exceeds the network capacity to satisfy 
discrete transmission media sources (12). A transmission the demand on a single channel or contiguous media 
plan (16) may be used to map a network transmitter (18) resource. For example, the class of service requires a con- 
through a link (14) to a predefined transmission media 20 nection that exceeds the bit rate capacity of the modulator at 
resource (12). For example, transmission network transmit- a particular transmitter, but two modulators would supply 
ter (20), in particular transmitter (18), may be mapped ample bandwidth for the class of service. In that instance, the 
through transmission plan (16) to two discrete segments (10) IC or the management component could divide a packet data 
through link (14). The network media resource may be a star stream from the end-user device onto the two different 
topology as shown in FIG. 1 or a mesh topology as shown 25 modulators. In that instance, multiple transmission media 
in FIG. 2. resources may be allocated to satisfy the overall class of 

Network transmission media resources may also be on service demand, 
separate networks. For example, a first network transmission A further representative example of a transmission plan 
resource may be capacity from the INMARSAT satellite employed herein is a broadcast from IC (38) through trans- 
network or through private networks on a C, KU, KA or 30 mitter (56) which has been allocated transmission media 
L-Band. The network transmission resources may be further resource (57). Transmission media resource (57) may be 
augmented by low earth orbiting satellites, medium earth used for reception by both IC (34) and receiver (58) and IC 
orbiting satellites or geosynchronous satellites. Low earth (32) and receiver (60). This is an example of a point to 
orbiting satellites may be represented by the Iridium system multi-point broadcast. The point is represented by uplink 
employed by Iridium, Inc., whose discrete bandwidth alio- 35 transmitter (56) and the multi-points are represented by 
cation methodology is herein incorporated by reference. receivers (58) and (60). One representative application of 
Geosynchronous satellites may also provide additional such a plan is, for example, a broadcast message from 
transmission resources as represented by the Inmarsat or transmitter (56) to two simultaneous sites represented by ICs 
Intelsat satellite services whose bandwidth allocation meth- (32) and (34). 

odologies are herein incorporated by reference. 40 Another representative example of a transmission plan 
The management component or the ICs do not need to be employed herein is transmitter (57), under control of IC 
in direct control of the bandwidth allocation to utilize (38), having an allocation of transmission media resource 
transmission media sources. For example, bandwidth alio- (61) for reception by receiver (54). IC (36) has transmitter 
cation on the Iridium satellite system may operated inde- (52) and transmission media resource (53) allocated for 
pendently of the management component and the ICs. 45 reception by receiver (50) at IC (38). This transmission plan 
However, the bandwidth allocation methodologies of, for may represent an asymmetric transmission, i.e., the out- 
example, the Iridium network, may be employed to treat the bound channel from IC (38), represented at transmitter (57), 
resultant communication path as a transmission media has more media resources allocated which may indicate a 
resource under control of the management component. higher bandwidth or higher data rate for reception by IC (36) 
Indeed, multiple carriers from a third-party system may be 50 through receiver (54) than the outbound channel from IC 
allocated in discrete predefined units, such as discrete seg- (36) through transmitter (52) through transmission media 
ments (10), shown in FIG. 18, for utilization by the present resource (53) for reception by receiver (50) to IC (38). Other 
invention as a media resource. representative permutations of the transmission plans 
FIG. 19 is a graphical depiction of network elements, ICs, employed herein are shown in FIG. 19 through the mapping 
a management component and a transmission plan. A central 55 transmission plan (43). 

controller of the present invention may be represented by FIG. 20 demonstrates the timing of how a representative 

Management Component ("MC") (30). MC (30) is in com- transmission plan may be implemented by the management 

munication with a plurality of ICs ("ICs") (32, 34, 38, 40) component. The transmission plan implementation begins 

through links (31). Each IC may represent a particular site with management component (100) having a predetermined 

that is under network management control by the MC. Each 60 command (102) to send to the network at a predetermined 

IC may have network equipment (42) under its control. For command time (110). Command(s) (102) is sent to IC (104) 

example, IC (40) has transmitter (44) under its control and that must change transmission resource allocation at the 

BIC (38) has receivers (46, 48, 50, 51) and transmitters (56, implementation time. This command is stored in IC (104) 

57) under its control. I C (36), however-, has receiver (54) and and the time to implement the command is decoded by IC 
transmitter (52) under its control. The present invention's (104). IC (104) then sends a command acknowledgment 

implements a transmission plan (43) through a mapping of , (118) back to a management component (100). At this 

network equipment (42) to transmission media resources juncture, command (102) is loaded and awaits deployment 
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at MC (100) at the predetermined command time (110). network device through a serial port (164, 166, 172, 174) or 
Command (102) is resent (122) if acknowledgment of a parallel port (188, 190). Command queues (168, 180, 184) 
receipt of command (118) is not received before a prede- may be a polled or interrupt driven queue. That is, the 
termined time, schedule command implementation process (164) may peri- 
It is understood that MC (100) may have a list of every IC 5 odically poll queues (168, 180, 184) to determine whether a 
(104) in the network that must change. This list may include command is present, and if so, pass the command on to the 
the TCP/IP address for each I C (104) so MC (110) may send appropriate network device interfaced (e.g., serial device 
a UDP/IP message with a command (102) encoded therein. driver (164, 166)) or the command key may be a period. 
An acknowledgment deadline (134) is included that may be The command queue may alternatively be interrupt 
seconds before the implementation time for the new trans- 10 driven. That is, when a command enters queue (168, 180, 
mission plan. The acknowledgment deadline (134) may be 184), for example, command queue (168) may send an 
the last time at which MC (106) can abort an implementation interrupt to the command implementation process for the 
if each IC (104) does not acknowledge the commands. command implementation process to service the command 
It is understood that IC (104) may use a coordinated and then pass it to the appropriate network device at the 
implementation to assure that no IC (104) is stranded when 15 appropriate serial port. It is understood that this process may 
the transmission plan is implemented. During the abort be used for implementation processes (170, 186) as well, 
sequence, which occurs if IC (104) has not acknowledged Command implementation processes (168, 170, 186) may 
command (102) at step (118), MC (106) sends an abort be synchronized to network time (202) to execute corn- 
message (126) to IC (108) that were sent command (102). IC mands at the appropriate time. That is, implementation of 
(108) may send an abort acknowledgment (128). Abort 20 transmission plans may be synchronized with network time 
command (126) is resent at step (130) if it is not acknowl- (202) to assure that all network devices reconfigure them- 
edged. The implementation time (136) defines a time at selves simultaneously or near simultaneously. Implementa- 
which the transmission plan is executed by IC (104). It is tion processes (168, 170, 186) may also have data from 
understood that at that point, all necessary ICs (104) have configuration database (152) to configure implementation 
acknowledged command (118) and are counting down in a 25 process (168, 170, 186) for the particular end-user network 
synchronized fashion to the predetermined implementation device. This provides flexibility in implementation process 
time (136). It is understood that the command acknowledged (168, 170, 186). That is, the implementation may be written 
may include an indication of the time at which an IC (104) as a modular software program which may be modified by 
received command (102) to verify that the implementation configuration database data (160) as implementation process 
time (136) is synchronized among each IC (104). Once all 30 (168, 170, 186) executes. Further to this concept is that MC 
commands have been acknowledged and the network is (156) may address configuration database (152) via link 
ready to implement the plan, at implementation time (136), (204) to change configuration database (152) to redefine the 
the ICs (104) implement the command(s) received from MC end-user equipment. This allows the MC (156) to manage 
(100) at implementation time (136). the end-user equipment remotely from the user location at 
At this point, a new transmission plan, as depicted in FIG. 35 the IC site. IC (150) may communicate through module 
19, may be implemented by the network. The communica- (158) via link (182) to send acknowledgments (200) back to 
tion path between MC (30) and ICs (32, 34, 36, 38, 40) is the MC (156). Command acknowledgments (118) shown in 
independent of the transmission media resources. As FIG. 20 and order acknowledgments may also be used, 
depicted in FIG. 19, a transmission path (31) is generally FIGS. 21-28 illustrate a step that may be used to confirm 
over a TCP/IP network (e.g., the Internet), as widely known 40 receipt of commands or to confirm receipt of an abort 
in use today. However, it is within the scope of the present command. 

invention to define a guard or maintenance channel which It is understood that there are at least two ways in which 

may be a point-to-multi-point transmission scheme from to map MC commands or at least two ways in which to map 

MC (30) to and from ICs (32, 34, 36, 38, 40) wherein an IC MC commands to the end-user device or to a particular port 

co-located with MC (30) assures that a network connection 45 on a IC. First, a TCP/IP address is provided for the IC in 

is present between ICs (32, 34, 36, 38, 40) and a MC command (204) and then, within the UDP command, is a 

allocated transmitter, such as transmitter (44). In such a case, sub-address that may be decoded at (158) addressed to a 

each IC (32, 34, 36, 38, 40) ready to implement the new particular end-user device. 

transmission plan may have a receiver dedicated to monitor FIG. 22 shows a graphical block diagram of an audit 

transmitter (44) to receive abort command (126) if each IC 50 control process by which the present invention may collect 

(32, 34, 36, 38, 40) does not acknowledge. This assures a fail data from network equipment. Equipment controller (150) 

safe or guard channel back-up plan to abort implementation may have a configuration database (152) which controls the 

of a new transmission plan if one or more IC (32, 34, 36, 38, configurations of the IC in relation to the end-user network 

40) loses communication with the management component. equipment. An audit request (252) may be received from the 

Commands may enter the IC (150) from a plurality of 55 MC via port (254). Port (254) may be a user data packet via 

sources, one of which may be directly from the MC. Node a TCP/IP network to a particular predetermined address at 

(158) may be a UNIX daemon or a Windows NT™ service (256). At (256), an auto request command may be decoded 

which monitors a TCP/IP address. Thus, commands from to map an equipment name to hardware identification from 

MC (156) may enter IC (150) through a port (204). Upon those stored in configuration database (152). The process at 

entering IC (150), network commands may be mapped at 60 (256) may also be used to map equipment attributes to data 

step (158) in conjunction with configuration database infer- controls (290). These parameters may be passed to the 

mation to output specific commands (178) to the network reformat command process at (280) which is used to provide 

equipment. These commands may be put into a command a formatted audit response (282) to the MC. 

queues (168, 180, 184) which is then directed through a In one embodiment of the present invention, the MC may 

scheduler process 162, 170 and 186. For example, scheduled 65 establish an asynchronous data collection process (262, 264, 

command implementation processes (162, 170, 186) may 266) for the network equipment at a respective data port 

output commands to the appropriate receiver, transmitter or (268, 270, 272, 274, 276, 278) for the network equipment. 
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Asynchronous data collection process (262, 264 266) may 
be interrupt or poll driven. 

In the interrupt driven embodiment of asynchronous data 
collection process (262, 264, 266), the end-user device may 
send out an unsolicited command via the respective device 
(e.g., device 268), to asynchronous data collection process 
(262, 264, 266). The interrupt then invokes the program to 
service the data condition (or possibly an alarm) from the 
network equipment. Asynchronous data collection process 
(262, 264, 266) then moves the data to the data control store 
block (258) where the alarm or data condition may be stored 
in the IC. It is understood that the data control store block 
(258) may be a hard drive or other long term storage means 
available at the BIC. In a preferred embodiment, the data 
control store is a non-volatile data storage media and the 
asynchronous data collection process is a modular program 
because it is modified from data from configuration database 
(260) for the particular network device. This provides a 
flexible programming methodology for the asynchronous 
data collection process employed in the present invention. 

In the polled embodiment of asynchronous data collection 
process (262, 264, 266), asynchronous data collection pro- 
cess (262), for example, may periodically pole the end-user 
network device attached to, for example, port (268), to 
receive data or alarm conditions from the end-user device. 
The polling rate may be a parameter from the configuration 
database received via link (260). 

In sum, an audit request may be received via port (254) 
and decoded at (256) to output data from the data control 
store program (292). Data output from the data control store 
may be formatted at (280) from parameters past (290) from 
the audit request. This can provide an auto response (294) 
back to the BMC (282) in the appropriate and predetermined 
format. 

FIG. 23 shows a logic flow representation of a network 
audit from a MC (302). In FIG. 23, the MC (302) may 
establish an auto time for a network element, a transmitter 
or receiver (300). At the appropriate time, MC (302) may 
send out an audit request (306). It is understood that audit 
request (306) is directed to the network element and the 
particular IC controlling that element (308). The IC may 
then query the network element and send an audit reply 
(312) to the MC (310). Audit reply (312) is shown in time 
synchronization (316) after audit request (306). 

Initialization or configuration files may be used to imple- 
ment the invention. For example, a "command.ini" file may 
be used to provide user interface command definitions for all 
network management system equipment supported. The 
"command.ini" file specifies the menus associated with each 
control used on a user display. 

A "monitor.ini" file may be used to specify automatic 
monitoring functions performed by an equipment controller. 
The "monitor. ini" file may act as the network management 
system data connection interface definition file. 

An "equiptcl.ini" file may be used as the network man- 
agement system controller initialization file. That is, the 
"equipctl.ini" file specifies some global parameters for the 
equipment controller application. It may also specify the 
location of other configuration files if such files are not 
stored in a default or pre-determined location. 

An "event.ini" file may provide descriptions of network 
management system events. For example, the "event.ini" file 
may specify textual responses (to user commands) displayed 
on a user interface and the asynchronous messages sent to 
either an event logger or other device. 

A "port. ini" may be used as the network management 
system external connection definition file. The "port.ini" file 
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may specify particular serial and parallel ports used by the 
equipment controller application. 

A "serial.ini" file may be used as the network manage- 
ment system serial command description file. This file may 

5 specify the command and response strings used to commu- 
nicate with the manage equipment over a serial interface. 

A of a network management system user interface defi- 
nition file ("panel.ini" file) may be provided. The "panel.ini" 
file may be an the overall specification for the display 

10 controller presentation. This file ties together the display 
controls with specific input/output ports and describes the 
total graphic user interface for an equipment controller site. 

A "template.ini" file may be used as the network man- 
agement system display template description file. This file 

as specifies the graphic qualities of the controls used in the 
display controller presentation. Graphic qualities may 
include the position of the graphic control on a display,the 
type of display object, the name of any required bitmap 
graphic file, and a reference to any menu associated with the 

20 control. 

The hardware identification field (1510) may contain 
information that identifies a specific transmitter or receiver 
at a site. The hardware identification field may have the 
format: 

25 HWID=<Class>:<Name> 
where 

<Class> is the type of hardware and 
<Name> is the name assigned to a specific piece of 
30 hardware in the IC configuration. 

The type of hardware may be one of the following classes: 
Transmitter (TX) 
Receiver (RX) 
Upconverter (UC) 
35 Downconverter (DC) 

The <Class> portion of the hardware identification field 
may be one of the mnemonics shown in parentheses. Infor- 
mation fields (1524) and header fields (1528) may share 
some similarities. Each type of field is terminated with an 
40 ASCII linefeed (LF) character (1512, 1522). The primary 
difference between header fields (1528) and information 
fields (1524) is that the same header fields are found in all 
system messages while different messages can have different 
information fields. 
45 Because of the size of information fields (1524), the 
format of an information field is more complex than the 
format of a header field. Information fields may match the 
format: 

<mnemonic>=<value> 
50 where 

<mnemonic> is a mnemonic representing the field type 
and 

<value> is a string representation of the field value. 
55 Both the mnemonic and the value of an information field 
may consist of printable ASCII characters. However, the 
ASCII character is used to separate the mnemonic and 
value portions of an information field. Therefore, cannot 
be present is either the mnemonic or value strings. 
60 A transmission control order (TCO) is sent from manage- 
ment component to an IC to request parameter changes for 
a transmitter or receiver controlled by the IC. A TCO may 
have has the following information fields: 
Execution time 
65 Model parameters 

The execution time field specifies the time at which the 
TCO must be implemented. The TCO for each side of a 
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communication link (transmitter and receiver) may have the might manually change the receiver frequency using the 

same execution time to minimize the time the carrier is down front panel of the equipment. The management component 

during the change. Execution times may be given in UTC. periodically requests the current state of all managed equip- 

The execution time field may have the format: ment to check for parameter modifications not initiated by 

ET=<YYYYxMM><DD><hhxmm> 5 lne management. The execution time for an audit response 

where is tne ume at which the ARSP is generated. 

<YYYY> is the four-digit year number (0000 to 9999), ^ ^ m ^ c ? ntain the model Parameters for the type 

. . . , , . of equipment specified by the hardware identification. When 

<MM> is the two-digit month number (January is 01 , ^ vaJue for a model parameter b not avai i ab i e , the value 

etc ^ 10 portion of the field may be "UNKNOWN". For example, if 

<DD> is the two-digit day of the month (01 to 31), tne scrambling state of a transmitter cannot be determined 

<hh> is the two-digit hour of the day (00 to 23), and by an IC, the field "SCR=UNKNOWN" may appear in the 

<mm> is the two-digit minute of the hour (00 to 59). audit response. 

All of the fields in a TCO after the execution time are The IC (° C) may read its configuration files at startup and 

model parameters. These fields are the parameter values for is construct memory resident database tables and data 'objects' 

the transmitter or receiver specified by the hardware iden- to facilitate rapid access to the configuration information 

tification field of a TCO. Model parameters are specified as stored in those files. Among the data read from the configu- 

a parameter/value pair. The format of a model parameter in ration files are the records that describe the equipment that 

a BMF message is: the Management Console (MC) application will attempt to 

<mnemonic>«<value> 20 control by its commands to the Equipment Controller. The 

where MC may communicate with the Equipment Controller in 

<mnemonic> is the mnemonic for a model parameter and message with a format similar to: 

<value> is a string representation of the parameter value. Equip=Equipmentaass:EquipmentUnitName 

An abort order (ABRT) may be sent to an IC to cancel any Attributel=Valuel 

pending TCO for the specified hardware. An ABRT does not 25 Attribute2«Value2 

require any information fields. where 'EquipmentClass* and 'EquipmentName' are charac- 

An acknowledgment (ACK) informs the management ter string values that occur in the IC configuration files as 

component that the IC received the TCO or ABRT An ACK identifying a piece of modeled equipment. The values of 

is the response message for a TCO or ABRT. When an IC 'Attribute' and 'Value' are also represented as character 

receives a TCO or ABRT, it must send an acknowledgment 30 strings and hence the entire dialog between the MC and IC 

to the management component. If the IC detects any prob- is through text based messages, 

lems with the TCO (configured hardware does not support a The IC configuration files identify one or more pieces of 

model parameter, hardware ID invalid, etc.) then the, ACK modeled equipment and a set of attributes that the modeled 

will describe the problems. An ACK for an ABRT does not equipment can support. For example, the following section 

require this problem description. An ACK may have the 35 of an 'equipctl.ini' file describes an equipment element 

following information fields: known as 'TRANSMITTER: Outbound'. The modeled 

Execution time (same as in TCO) attributes are identified by the 'EquipModemAttrs* entry and 

Model parameters (only if an error condition exists) list the values TXF MODT MODR ENCT ENCR 

An ACK may have the same information fields as the 40 DENC SCR PWR CXR as the legitimate attributes of the 

TCO that is being acknowledged. However, model param- unit as 'TRANSMnTER:Outbound*. 

eter fields are only present if the IC cannot fulfill that model [Outbound] 

parameter. For example, if the TCO contained an invalid EquipName^Outbound 

receiver bit rate but a valid receiver frequency then the ACK EquipClass=TRANSMITTER 

would include an information field for the RXR model 45 EquipModelAttrs^ALL TXF TXR MODT MODR ENCT 

parameter but not for the RXF model parameter. EN CR DENC SCR PWR CXR 

An audit request (AREQ) is sent periodically bytheMC EquipAttrSetCmds = "" EFDataTxfSetCmd 

for each transmitter and receiver in a satellite network. Each EFDataTxrSetCmd EFDataModtSetCmd 

AREQ is sent to the BMF IC responsible for managing the EFDataModrSetCmd EFD at aEnctSe tCmd 

specified transmitter or receiver. An AREQ does not require 50 EFDataTxrSetCmd EFDataDencSetCmd 

any information fields. EFDataScrSetCmd EFDataPwrSetCmd EFDataCarri- 

An audit response (ARSP) is sent by an IC in response to erSetCmd 

an AREQ from the MC. An ARSP is the response message EquipAttrSetCmdParms="TXF TXR ENCT PWR" "TXF" 

for an AREQ. An ARSP has the following information "ENCR TXR" "MODT" "MODR" 

fields: 55 "ENCT" "ENCR TXR" "DENC" "SCR" "PWR" "CXR" 

Execution time (time ARSP generated) EquipAttrSetCmdPorts=Serial5 

Model parameters (actual settings) EquipAttrSetCmdAddrs^T* 

The format of an ARSP may be almost identical to the EquipAttrMonConns-"" EFDataTxfMon EFDataTxrMon 

format of a TCO: the message contains an information field EFDataModtMon 

for all of the model parameters pertaining to the specified 60 EFDataModrMon EFDataEnctMon EFDataEncrMon 

piece of hardware. However, the values of the model param- EFDataDencMon 

eters may be the actual settings of the hardware, not the EFDataScrMon EFDataPwrMon EFDataCarrierMon 

desired settings. EquipAttrMonConnPorts»Serial5 

One purpose of the ARSP is to determine the state of the EquipAttrMonConnAddrs="l" 
hardware in the network, A secondary purpose is to check 65 AssociatedEquipment=RECEIVER:Demodl 
for manually instituted changes to the configuration of the This configuration entry may also associate other con- 
network hardware. For example, an operator at a remote site figuration entries with the equipment attributes that permit 
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the equipment controller to set (modify) and get (recover) eating why the request cannot be implemented. Validation of 

the attribute values from an actual piece of serially attached the parameter values may also be accomplished in a similar 

equipment. The entries in the list of 'EquipAttrSetCmds 1 technique. 

refer to entries in the 'seriaUni* file that describe the actual If the request is otherwise correct, but the equipment is 

command to be sent. The entries in the ' Equip AttrSetCm- 5 currently not responding to serial commands, no response is 

dPorts* and 'EquipAttrSetCmdAddrs' describe which serial purposely generated, which may indicate that no problem 

port the attached equipment is connected to and the address was detected in the request but that the since no acknowl- 

of the attached equipment (in the case that multiple pieces of edgment was sent, the request will not be implemented at the 

equipment are attached via the same serial port). Similarly, specified time. Otherwise, an acknowledgment is returned to 

the 'EquipAttrMonConns' entry refer to configuration 10 the MC indicating that unless otherwise instructed, the IC 

entries in the 'monitor.ini* file that describe the mechanism will perform the requested configuration change at the 

by which the attribute is recovered from the attached equip- requested time. The request to cancel the modification of the 

ment and the ' Equip AttrMonConnPorts' and 'EquipAttr- attributes of a particular piece of equipment is known as a 

MonConnAddrs* describe the serial ports and addresses used Abort Message (ABRT). The format of an ABRT is as 

for data recovery. is follows: 

Hence the IC is in not actually aware of the semantics of ABRT 

the data values it is 'setting' or 'getting* and the mapping MessageSequenceNumber 

between the equipment and equipment attributes that the „ . „ . ^ ^ . TT . vr 

MC believes it is controlling is completely defined by the ^uip=Equipmentaass : EquipmentUmtNarne 

equipment controller configuration files and not equipment 20 . ^ IC u ma y remo ^ e ,he outstandmg command set to be 

controller software issued to the specified equipment if any command is queued 

Tie MC and IC communicate via the text format gener- an d ma ? send an acknowledgment to the MC indicating it 

ally described above. All communication is initiated by the has dor > e so ' If > at the tune ° f r6 f ^ no ^mand is 

MC. Three request packets are currently denned: 1) a outstanding, the IC may respondwith a message indicating 

request to modify the attributes of a particular piece of 25 that n0 «>[nmand was found. The request to recover the 

equipment at a particular time in the future, 2) a request to current values of the a «nbutes of a particular piece of 

cancel the request to modify the attributes of a particular equipment is known as an Audit Message (AUDI r). Ihe 

piece of equipment, and 3) a request to return the current format of an AUDIT is as follows: AUDIT 

values of the attributes of a particular piece of equipment. MessageSequenceNumber 

Each request is normally responded to with a complemen- 30 Equip=EquipmentClass:EquipmentUnitName 

tary message. In some cases, however, no response message AttributeName (optional) 

purposely generated in order to communicate a negative AttributeName (optional) 

response. The MC may request the current values of the equipment 

The request to modify the attributes of a particular piece attributes by an AUDIT message to the IC. The 

of equipment is known as a Transmission Change Order 35 message may comain dfic attribute names or> in the 

(TCO). The format of a TCO is as follows: absence of any attribme names> all attributes associated with 

MessageSequenceNumber the equipment are returne d. Should the equipment or 

Eqmp=Eq^mentCl^|Equipmen tUnitName attributes identified not be defined in the IC configuration, 

tT i/ i i lhe IC wiU send a messa 8 e similar 10 lhe negative acknowl- 

Attnbutel=Va uel 40 edgrrient t0 a TCO i ndicating what particular field of the 

Attnbute2=Value2 request message was found in error. If the AUDIT request 

When the IC receives a TCO it validates the request. The m e is found tQ be ted b the curTent IC 

request validation includes confirming that the requested configuration) the IC may will use the configuration entries 

change time has not already past and that the IC configu- identifled by the < equi pctl.ini' file to recover the current 

ration supports the requested modifications^ IC may 45 va i ues an d will form a response message similar to the TCO 

refer to its memory resident database of configuration data m e and ^ it tQ , he MC The K e m e 

to validate request. First, the IC may insure that the format is as follows: 

requested equipment is identified in the configuration. It AUDIT 

then may insure, by tracing the attributes named in the MessageSequenceNumber 

request through the configuration to the commands that must 50 Equip=EquipmentClass:EquipmentUnitName 

be issued to insure that sufficient configuration information Time-YYYYMMDDHHMM 

is present to form the required commands. Finally it may Atlributel-Valuel 

check to see if the equipment is currently responding to Altribute2»Value2 

commands. The Implementation component (IC) reads its configura- 

If an error is detected such that the request cannot be 55 tion files at startup and constructs memory resident database 

supported by the configuration, a response may be returned , ables and data lobjects> tQ facilita(e id access , 0 , he 

to the MC identifying the offending request data. For configuration m f ormat ; on slore d in those files, 

example, !f a request contained an equipment identification Am0Qg , he data fead from ^ 

configuration files are the 

that did not exactly match an entry in the equipctl.im file recQrds lha( describe , he ^ ^ (he Ma ent 

or if an attribute name did not exact y match one of the 60 Console (MC) application ^ att , t0 comro , b its 

legitimate attributes named in the equipctl.im file a commands to the Equipment Controller. The MC will com- 

response would be sent indicating why the TCO was invalid municate wi(h ^ , controller in message with a 

and implicitly indicating that the request would not be format similar to* 

implemented. Further, if a legitimate attribute is named, but . . ' , _ . . r 

the equipment controller finds that either no serial command 65 Equip=EquipmentClass:EquipmentUmtName 

is referenced or that the referenced serial command is not Attribute 1 -Valuel 

configured, the IC may also send a similar response indi- Attribute2=Value2 



01/20/2004, EAST Version: 1.4.1 



US 6,381,250 Bl 

23 24 

where 'EquipmentClass* and 'EquipmentName* are charac- equipment at a particular time in the future, 2) a request to 

ter string values that occur in the IC configuration files as cancel the request to modify the attributes of a particular 

identifying a piece of modeled equipment. The values of piece of equipment, and 3) a request to return the current 

'Attribute* and ' Value* are also represented as character values of the attributes of a particular piece of equipment, 

strings and hence the entire dialog between the MC and IC 5 Each request is normally responded to with a complemen- 

is through text based messages. tary message. In some cases, however, no response message 

The IC configuration files identify one or more pieces of purposely generated in order to communicate a negative 

modeled equipment and a set of attributes that the modeled response. 

equipment can support. For example, the following section The request to modify the attributes of a particular piece 

of an 'equipctl.ini' file describes an equipment element 10 of equipment is known as a Transmission Change Order 

known as 'TRANSMITTER: Outbound 5 . The modeled (TCO). The format of a TCO is as follows: 

attributes are identified by the ' EquipModemAttrs* entry and TCO 

list the values TXF TXR MODT MODR ENCT ENCR MessageSequenceNumber 

DENQSCR PWR CXR as the legitimate attributes of the Equip«EquipmentClass:EquipmentUnitName 

unit known as 'TRANSMITTER:Outbound\ 15 Time«YYYYMMDDHHMM 

[Outbound] Attributel=Valuel 

EquipName=Outbound Attribute2oValue2 

EquipClass=TRANSMITTER When the IC receives a TCO it validates the request. The 

EquipModclAttrs=ALL TXF TXR MODT MODR ENCT request validation includes confirming that the requested 

ENCR DENC SCR PWR CXR 20 change time has not already past and that the IC configu- 

EquipAttrSetCmds = "" EFDataTxfSetCmd ration supports the requested modifications. The IC refers to 

EFDataTxrSetCmd EFDataModtSetCmd its memory resident database of configuration data to vali- 

EFDataModrSetCmd EFDataEnctSetCmd date request. First the IC insures that the requested equip- 

EFDataTxrSetCmd EFDataDencSetCmd ment is identified in the configuration. It then insures, by 

EFDataScrSetCmd EFDataPwrSetCmd EFDataCarri- 25 trac j. n S the attrib L utes ™nwd * request the 

erSetCmd configuration to the commands that must be issued to insure 

EquipAttrSetCrndParms-"TXF TXR ENCT PWR" "TXF" ^ at sufficient configuration information is present to form 

ENCR TXR" "MODT" "MODR" required commands. Finally it checks to see if the 

((OKr ™ tvd" "t^cmo" «cr-D» «m\/D» «i^yd» equipment is currently responding to commands, 

r, . 0 ^5™ . « 30 If an error is detected such that the request cannot be 

EquipAttrSetCmdPorts^SerialS supported by the configuration, a response is returned to the 

EquipAttrSetCmdAddrs= 1 MC identifying the offending request data. For example, if 

q nl?n w EFDataTxfMon EFDataTxrMon a fequest contained an equipment identification that did not 

EFDataModtMon exactly match an entry in the < equipctLirii > fite or if an 

EFDataModrMon EFDataEnctMon EFDataEncrMon 35 attribute name did not exactly match one of the legitimate 

EFDataDencMon attributes named in the 'equipctl.ini' file, a response would 

EFDataScrMon EFDataPwrMon EFDataCarrierMon be sent indicating why the TCO was invalid and implicitly 

Equip AttrMonConnPorts=Serial5 indicating that the request would not be implemented. 

Equip AttrMonConnAddrs«"l " Further, if a legitimate attribute is named, but the equipment 

AssociatedEquipment=RECEIVER:Demodl 40 controller finds that either no serial command is referenced 

This configuration entry also associates other configura- or that the referenced serial command is not configured, the 

tion entries with the equipment attributes that permit the IC will also send a similar response indicating why the 

equipment controller to set (modify) and get (recover) the request cannot be implemented. Validation of the parameter 

attribute values from an actual piece of serially attached values may also be accomplished in a similar technique, 

equipment. The entries in the list of ' EquipAttrSetCmaV 45 If the request is otherwise correct, but the equipment is 

refer to entries in the 'serial.ini* file that describe the actual currently not responding to serial commands, no response is 

command to be sent. The entries in the ' Equip AttrSetCm- purposely generated, indicating that no problem was 

dPorts' and ' Equip AttrSetCmdAddrs* describe, which serial detected in the request but that the since no acknowledgment 

port the attached equipment is connected to and the address was sent, the request will not be implemented at the speci- 

of the attached equipment (in the case that multiple pieces of 50 fied time. 

equipment are attached via the same serial port). Similarly, Else an acknowledgment is returned to the MC indicating 

the 'EquipAttrMonConns' entry refer to configuration that unless otherwise instructed, the IC will perform the 

entries in the ' monitor.ini* file that describe the mechanism requested configuration change at the requested time, 

by which the attribute is recovered from the attached equip- The request to cancel the modification of the attributes of 

ment and the 'EquipAttrMonConnPorts* and 'EquipAttr- 55 a particular piece of equipment is known as a Abort Message 

MonConnAddrs' describe the serial ports and addresses used (ABRT). The format of an ABRT is as follows: 

for data recovery. ABRT 

Hence the IC is in not actually aware of the semantics of MessageSequenceNumber 

the data values it is 'setting* or 'getting* and the mapping Equip=*EquipmentClass:EquipmentUnitName 

between the equipment and equipment attributes that the 60 The IC will remove the outstanding command set to be 

MC believes it is controlling is completely defined by the issued to the specified equipment if any command is queued 

equipment controller configuration files and not equipment and will send an acknowledgment to the MC indicating it 

controller software. has done so. If, at the time of receipt, no command is 

The MC and IC communicate via the text format gener- outstanding, the IC will respond with a message indicating 

ally described above. All communication is initiated by the 65 that no command was found. 

MC. Three request packets are currently defined: 1) a FIG. 13 depicts a flow chart of a transmission plan 

request to modify the attributes of a particular piece of execution. Initially, the system may have an unscheduled 
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transmission (1302), The transmission plan may be assigned 
an execution time (1304). The transmission plan may be 
propagated to the network to place the plan onto a pending 
status (1306). After all of the TCO's required to implement 
the transmission plan have acknowledged the command, the 
transmission plan is ready for execution (1308). At the 
transmission plan execution time (1310) the plan began the 
start sequence. After the MC confirms that all TCO's have 
been confirmed, e.g., so that the MC does not issue an abort 
command, the transmission plan goes active (1312). 

The system then begins normal operation on the new 
transmission plan and the system begins collecting data 
again on link usage (1316). Special transmission plans, e.g., 
transmission plans that are not recurring, are not 
re-scheduled (1318). 

FIG. 14 depicts a bandwidth allocation request. This 
control loop may execute at the MC. The system may 
receive a request for bandwidth 1402 from the Bandwidth 
administrator or an IC. The request may be an unscheduled 
network event 1404. The request for bandwidth is decoded 
and scheduled for execution 1406. The execution schedule 
may be for immediate execution or for a scheduled deploy- 
ment. The appropriate TCO may be sent from the MC to the 
appropriate IC to propagate the transmission plan and to put 
the plan into the ready state 1408, The transmission plan 
then waits for its execution time. When the transmission 
plan execution time arrives (1410) the MC confirms that the 
TCO's were confirmed by the ICs. If the TCO's were 
confirmed, the plan goes active (1412) at the predetermined 
time the system has thereby fulfilled (1414) the bandwidth 
request. 

The IC may implement a control loop similar to that 
shown and described above. The IC may confirm that a 
channel is available within the present transmission plan 
1406 and immediately execute the new transmission pan 
1408, 1410 and 1412, The IC may then notify the MC 1402 
of the unscheduled 1404 transmission plan. The MC may 
then proceed as described above to propagate and deploy the 
new plan. 

FIG. 5 depicts the inter-process communication between 
the MC 502 and ICs (506) and 542. MC commands are sent 
via the UDP/IP link 504 from the control component 503 to 
the equipment control component 514. The equipment con- 
troller 514 then maps the generic network commands from 
the MC to specific commands (discussed above) for output 
(512) to the managed equipment (510). The equipment 
controller (514) may lose the command event (524). The IC 
may also denote the command event on the local display 
530. 

The system may receive alarm and other network mes- 
sages that may effect the network management display 518 
via the TCP/IP connection 516. Equipment controller 514 
may connect to the display controller 518 when the equip- 
ment controller 514 receives an alarm condition from the 
network equipment (510,520) via command links (512, 
522). The event logger (534) may receive network audits 
and network events from the IC 506 equipment controller 
(514) via UDP/IP link 532. As provided above, each of the 
communication processes on FIG. 5 may be interpret or poll 
driven. 

The IC may also denote the command event on the local 
display 530. 

The system may receive alarm and other network mes- 
sages that may effect the network management display 518 
via the TCP/IP connection (516). Equipment controller 
(514) may connect to the display controller (518) when the 
equipment controller 514 receives an alarm condition from 



10 



is 



20 



30 



35 



40 



45 



50 



55 



60 



65 



the network equipment (510,520) via command links (512, 
522). The event logger (534) may receive network audits 
and network events from the IC 506 equipment controller 
(514) via UDP/IP link (532). As provided above, each of the 
communication processes on FIG, 5 may be interrupt or poll 
driven. 

Other embodiments and uses of the invention will be 
apparent to those skilled in the art from consideration of the 
specification and practice of the invention disclosed herein. 
The specification and examples should be considered exem- 
plary only. The scope of the invention is only limited by the 
claims appended hereto. 

Therefore we claim: 

1. A system for controlling a network of communication 
devices, each device communicating in the network accord- 
ing to a transmission plan specified by a management 
component of the system, the system comprising: 

a management component that controls the transmission 
plan for all communications devices in the network; 
and 

one or more implementation component that control one 
or more communication devices in the network accord- 
ing to instructions from the management component, 
each implementation component comprising: 
receiving means for receiving at least one transmission 
plan from the management component, said trans- 
mission plan containing a scheduled implementation 
time for modifying the transmission plan for one or 
more devices in the network; 
decoding means for decoding an implementation time 

for said transmission plan; and 
output means for outputting a command to a commu- 
nication device controlled by the implementation 
component to implement said transmission plan at 
the implementation time specified instead of the 
transmission plan currently being utilized by that 
communication device. 

2. A method for managing a communication network with 
an adaptive transmission plan, the communication network 
comprising a management component that controls the 
transmission plan for all communication devices in the 
network and one or more implementation components that 
control one or more communication devices in the network 
according to instructions from the management component, 
comprising: 

at the management component, analyzing network band- 
width allocation within the communication network 
over a predetermined period of time; 

at a management component, determining a transmission 
plan to accommodate, at least in part, the results of said 
analysis of said network bandwidth allocation; 

deploying said transmission plan from the management 
component to a plurality of implementation compo- 
nents to implement said transmission plan; 

said implementation component receiving the transmis- 
sion plan from the management component, the trans- 
mission plan containing a scheduled implementation 
time from modifying the transmission plan for one or 
more devices in the network, decoding an implemen- 
tation time for the transmission plan, and outputting a 
command to a communication device controlled by that 
implementation component to implement the transmis- 
sion plan at the implementation time specified instead 
of the transmission plan currently being utilized by that 
communication device; and 

at the management component, analyzing network band- 
width allocation short falls over a predetermined period 
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of time to identify a transmission plan that accommo- 
dates bandwidth demands. 

3. The system of claim 1 wherein the communication 
devices transmit and receive communication signals using 
predetermined transmission media resources. 5 

4. The system of claim 3 wherein the transmission plan 
allocates transmission media resources among communica- 
tion devices in the network. 

5. The system of claim 4 wherein the communication 
devices comprise transmitters and wherein the management 10 
component maps predetermined transmission media 
resources to transmitters. 

6. The system of claim 5 wherein the communication 
devices further comprise receivers and wherein the manage- 
ment component maps predetermined transmission media 15 
resources to receivers. 

7. The system of claim 6 wherein the transmission plan 
maps specific predetermined transmission media to at least 
one transmitter and at least one receiver for communication 
from the at least one transmitter to the at least one receiver. 2 o 

8. The system of claim 7 wherein the transmission plan 
maps a specific predetermined transmission media to one 
transmitter and a plurality of receivers for communication 
from the transmitter to the plurality of receivers. 

9. The system of claim 7 wherein the transmission plan 2 s 
changes at least one specific predetermined transmission 
media mapping and wherein the output means of the imple- 
mentation component transmits the transmission plan to at 
least one transmitter and at least one receiver affected by the 
change in mapping of the at least one specific predetermined 30 
transmission media. 

10. The system of claim 9 wherein the at least one 
transmitter and the at least one receiver implement the 
transmission plan simultaneously. 

11. The system of claim 9 wherein the scheduled imple- 35 
mentation time in the message received by the implemen- 
tation component for the at least one transmitter and the 
implementation component for the at least one receiver is 
the same time. 

12. The system of claim 1 further comprising a TCP/IP 40 
network that enables communications between the manage- 
ment component and the one or more implementation com- 
ponents for communication of the transmission plan 
between the management component and the implementa- 
tion components. 45 

13. The system of claim 1 further comprising a mainte- 
nance channel that enables communications between the 
management component and the one or more implementa- 
tion components for communication of the transmission plan 
between the management component and the implementa- 50 
tion components, 

14. The system of claim 1 wherein the communications 
devices comprises a satellite-based communication network 
and wherein the communication devices comprise network 
equipment for transmitting and receiving communications 55 
via satellite. 

15. The system of claim 1 wherein the management 
component comprises: 

determination means for determining the communication 
devices in the network affected by a transmission plan go 
to be implement; and 

transmission plan message creation means creating a 
message containing a transmission plan to be sent to the 
communication devices affected by the transmission 
plan. 65 

16. The system of claim 15 wherein the management 
component further comprises: 
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plan transmission means for transmitting the transmission 
plan to all communication devices affected by the 
transmission plan. 

17. The system of claim 16 wherein the management 
component further comprises acknowledgement deadline 
monitoring means for establishing an acknowledgement 
deadline by which all communications devices affected by 
the transmission plan are to send an acknowledgement and 
monitoring for acknowledgements from all of those com- 
munications devices. 

18. The system of claim 17 wherein the management 
component further comprises abort message means for send- 
ing an abort message to all communication devices affected 
by a transmission plan if an acknowledgement is not 
received from all communication devices affected by a 
transmission plan prior to the acknowledgement deadline. 

19. The system of claim 18 wherein the transmission plan 
message comprises a sequence number for a specific com- 
munication device and wherein the sequence number is used 
to determine if an acknowledgement is received from all 
communication devices to which the transmission plan was 
sent. 

20. The system of claim 1 wherein the network comprises 
a discrete bandwidth allocation network managed by an 
external system. 

21. The system of claim 1 wherein the network comprises 
semi-programmable medium network wherein a varying 
amount of bandwidth may be allocated from an externally 
managed resource. 

22. The system of claim 1 wherein the network comprises 
a fully-programmable network where the resources are 
managed by a network management component. 

23. The system of claim 1 wherein the network comprises 
a combination of one or more of the following: a discrete 
bandwidth allocation network managed by an external 
system, a semi -programmable medium network wherein a 
varying amount of bandwidth may be allocated from an 
externally managed resource, and a fully-programmable 
network where the resources are managed by a network 
management component. 

24. A system for controlling a network of communication 
devices, each device communicating in the network accord- 
ing to a transmission plan specified by a management 
component of the system, the system comprising: 

one or more implementation components that control one 
or more communication devices in the network accord- 
ing to instructions from the management component, 
each implementation component comprising: 
receiving means for receiving at least one transmission 
plan from the management component, said trans- 
mission plan containing a scheduled implementation 
time for modifying the transmission plan for one or 
more devices in the network; 
decoding means for decoding an implementation time 

for said transmission plan; and 
output means for ou (putting a command to a commu- 
nication device controlled by the implementation 
component to implement said transmission plan at 
the implementation time specified instead of the 
transmission plan currently being utilized by that 
communication device. 

25. The system of claim 24 wherein the communication 
devices transmit and receive communication signals using 
predetermined transmission media resources and wherein 
the transmission plan allocates transmission media resources 
among communication devices in the network. 

26. The system of claim 24 wherein the transmission plan 
maps specific predetermined transmission media to at least 
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one transmitter and at least one receiver for communication 
from the at least one transmitter to the at least one receiver. 

27. The system of claim 24 wherein the transmission plan 
changes at least one specific predetermined transmission 
media mapping and wherein the output means of the imple- 
mentation component transmits the transmission plan to at 
least one transmitter and the at least one receiver affected by 
the change in mapping for the at least one specific prede- 
termined transmission media. 

28. A method for controlling a network of communication 
devices, each device communicating in the network accord- 
ing to a transmission plan specified by a management 
component of the system, the method comprising the steps 
of: 

receiving at least one transmission plan from the man- 
agement component that is determined based on per- 
formance evaluation of an existing transmission plan, 
said transmission plan containing a scheduled imple- 
mentation time for modifying the transmission plan for 
one or more devices in the network; 

decoding an implementation time for said transmission 
plan; and 

outputting a command to a communication device con- 
trolled by the implementation component to implement 
said transmission plan at the implementation time 
specified instead of the transmission plan currently 
being utilized by that communication device. 

29. The method of claim 28 wherein the transmission plan 
maps specific predetermined transmission media to at least 
one transmitter and at least one receiver for communication 
from the at least one transmitter to the at least one receiver. 

30. The method of claim 28 wherein the transmission plan 
maps a specific predetermined transmission media to one 
transmitter and a plurality of receivers for communication 
from the transmitter to the plurality of receivers, 

31. The method of claim 28 wherein the transmission plan 
changes at least one specific predetermined transmission 
media mapping and wherein the output means of the imple- 
mentation component transmits the transmission plan to the 
at least one transmitter and at least one receiver mapped to 
the at least one specific predetermined transmission media 
changed by the transmission plan. 

32. The method of claim 31 wherein the at least one 
transmitter and at least one receiver implement the trans- 
mission plan simultaneously. 

33. The method of claim 31 wherein the scheduled 
implementation time in the message received by the imple- 
mentation component for the at least one transmitter and the 
implementation component for the at least one receiver is 
the same time. 

34. The method of claim 28 wherein the transmission plan 
is received over a TCP/IP network. 

35. The method of claim 28 wherein the transmission plan 
is received over a maintenance channel that enables com- 
munications between the management component and the 
one or more implementation components. 

36. The method of claim 28 wherein the network of 
communications devices comprises a satellite -based com- 
munication network. 

37. The method of claim 28 further comprising the steps 
of: 

determining the communication devices in the network 
affected by a transmission plan to be implemented; and 

creating a message containing a transmission plan to be 
sent to the communication devices affected by the 
transmission plan. 
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38. The method of claim 37 further comprising the step of: 
transmitting the transmission plan to all communication 

devices affected by the transmission plan. 

39. The method of claim 38 further comprising the steps 
of: 

establishing an acknowledgement deadline by which all 
communications devices affected by the transmission 
plan are to send an acknowledgement; and 
20 monitoring for acknowledgements from all of those com- 
munications devices. 

40. The method of claim 39 further comprising the step of 
sending an abort message to all communication devices 

15 affected by a transmission plan if an acknowledgement is not 
received from all communication devices affected by a 
transmission plan prior to the acknowledgement deadline. 

41. The method of claim 40 wherein the transmission plan 
message comprises a sequence number for a specific com- 

20 munication device and wherein the sequence number is used 
to determine if an acknowledgement is received from all 
communication devices to which the transmission plan was 
sent. 

25 42. The method of claim 28 wherein the network com- 
prises a discrete bandwidth allocation network managed by 
an external system. 

43. The method of claim 28 wherein the network com- 
prises a semi-programmable medium network wherein a 

30 varying amount of bandwidth may be allocated from an 
externally managed resource. 

44. The method of claim 28 wherein the network com- 
prises a fully-programmable network where the resources 
are managed by a network management component. 

45. The method of claim 28 wherein the network com- 
prises a combination of one or more of the following: a 
discrete bandwidth allocation network managed by an exter- 
nal system, a semi-programmable medium network wherein 

40 a varying amount of bandwidth may be allocated from an 
externally managed resource, and a fully-programmable 
network where the resources are managed by a network 
management component, 

46. The method of claim 2 wherein the transmission plan 
45 maps specific predetermined transmission media to at least 

one transmitter and at least one receiver for communication 
from the at least one transmitter to the at least one receiver. 

47. The method of claim 2 wherein the transmission plan 
maps a specific predetermined transmission media to one 

50 transmitter and a plurality of receivers for communication 
from the transmitter to the plurality of receivers. 

48. The method of claim 2 wherein the transmission plan 
changes at least one specific predetermined transmission 
media mapping and wherein the output means of the imple- 

55 mentation component transmits the transmission plan to at 
least one transmitter and at least one receiver affected by the 
mapping change for the at least one specific predetermined 
transmission media. 

60 49. The method of claim 48 wherein the at least one 
transmitter and at least one receiver implement the trans- 
mission plan simultaneously. 

50. The method of claim 49 wherein the scheduled 
implementation time in the message received by the imple- 

65 mentation component for the at least one transmitter and the 
implementation component for the at least one receiver is 
the same time. 
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51. The method of claim 2 wherein the transmission plan 
is received over a TCP/IP network. 

52. The method of claim 2 wherein the transmission plan 
is received over a maintenance channel that enables com- 
munications between the management component and the 5 
one or more implementation components. 

53. The method of claim 2 wherein the network of 
communications devices comprises a satellite-based com- 
munication network. 

54. The method of claim 2 further comprising the steps of: 10 
determining the communication devices in the network 

affected by a transmission plan to be implemented; and 
creating a message containing a transmission plan to be 
sent to the communication devices affected by the 
transmission plan. 35 

55. The method of claim 54 further comprising the step of: 
transmitting the transmission plan to all communication 

devices affected by the transmission plan. 

56. The method of claim 55 further comprising the steps 

of: 
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establishing an acknowledgement deadline by which all 
communications devices affected by the transmission 
plan are to send an acknowledgement; and 

monitoring for acknowledgements from all of those com- 
munications devices. 

57. The method of claim 56 further comprising the step of 
sending an abort message to all communication devices 
affected by a transmission plan if an acknowledgement is not 
received from all communication devices affected by a 
transmission plan prior to the acknowledgement deadline. 

58. The method of claim 57 wherein the transmission plan 
message comprises a sequence number for a specific com- 
munication device and wherein the sequence number is used 
to determine if an acknowledgement is received from all 
communication devices to which the transmission plan was 
sent. 

***** 
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